feat: add pantheon doctor command for environment diagnostics

Summary

Pantheon currently auto-checks for LLM provider API keys at startup
(check_and_run_setup), but has no way to surface other common
environment misconfigurations before execution begins.

This PR adds an explicit pantheon doctor command that makes the
project's existing environment contracts visible before a run starts,
following established CLI diagnostics patterns used by
flutter doctor, npm doctor, dbt debug, and brew doctor.

Motivation

Two concrete gaps this addresses:

1. Python version — pyproject.toml declares requires-python = ">=3.10",
but nothing checks this at runtime; mismatches only surface as cryptic
import failures.

2. Core package integrity — ipykernel, jupyter-client, and nbformat
are declared required dependencies. A broken or incomplete install
silently degrades notebook functionality with no clear diagnosis.

Additionally, the r optional-dependency comment in pyproject.toml
explicitly states "requires R installed on system". When a user installs
the r extra but does not have R on PATH, the failure is currently silent
until rpy2 is actually called.

Changes

No other files are modified.

What pantheon doctor checks

All checks are output-only. The command never modifies the system.

Design notes

Why doctor skips check_and_run_setup()

The existing guard in main() already skips the setup wizard when
sys.argv[1] == "setup". doctor is added to this skip list for the
same reason: running pantheon doctor should surface the environment
state, not trigger the interactive wizard. The one-character change
(!= "setup" → not in ("setup", "doctor")) makes this explicit.

Why _check_api_keys mirrors check_and_run_setup exactly

Rather than defining a new key-detection heuristic, _check_api_keys()
replicates the same four-step check from check_and_run_setup() in the
same order (SKIP_SETUP_WIZARD → PROVIDER_API_KEYS →
CUSTOM_ENDPOINT_ENVS → legacy LLM_API_KEY), so that doctor and the
startup wizard always agree on whether the environment is configured.

Non-goals

• Does not change any existing command's behavior
• Does not auto-trigger on any existing command
• Does not add new settings keys or configuration surface
• Does not introduce a component registration API
• Does not model downstream workflow requirements

Backward compatibility

None — this is a pure addition. All existing commands are unchanged.

Testing

pantheon doctor          # shows structured PASS/WARN/FAIL table
echo $?                  # 0 = pass/warn only, 1 = at least one FAIL

Manual test matrix: